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(1) Real Party in Interest 

A statement identifying by name the real party in interest is contained in the brief. 

(2) Related Appeals and Interferences 

The examiner is not aware of any related appeals, interferences, or judicial proceedings 
which will directly affect or be directly affected by or have a bearing on the Board's decision in 
the pending appeal. 

(3) Status of Claims 

The statement of the status of claims contained in the brief is correct. 

(4) Status of Amendments After Final 

The appellant's statement of the status of amendments after final rejection contained in 
the brief is correct. 

(5) Summary of Claimed Subject Matter 

The summary of claimed subject matter contained in the brief is correct. 

(6) Grounds of Rejection to be Reviewed on Appeal 

The appellant's statement of the grounds of rejection to be reviewed on appeal is correct. 

(7) Claims Appendix 

The copy of the appealed claims contained in the Appendix to the brief is correct. 

(8) Evidence Relied Upon 

5,819,291 Haimowitz et al. 10-1998 

2002/00691.95 Commons etal. 6-2002 

5,806,058 Mori etal. 9-1998 

5,276,616 Kugaetal. 1-1994 
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6,070,164 Vagnozzi 5-2000 

(9) Grounds of Rejection 

The following ground(s) of rejection are applicable to the appealed claims: 

Claims 1, 4, 5, 7, 8, 15, 17-19, 21 and 23 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Haimowitz et al. (US Patent 5,819,291) of record, hereinafter 
"Haimowitz", in view of Commons et al. (US Patent Pub 2002/0069195) of record, 
hereinafter "Commons". 

In regards to claim 1, Haimowitz discloses a heuristics analysis tool embodied in a 
computer-readable storage medium, comprising: 

a. a persistent table, having clean data records and key records wherein at least one 
key record is associated with each clean data record, each key record having at least one 
field of data from the associated clean data record (Col. 2, lines 63-66; col. 4, lines 65-67; 
col. 5, lines 1-8) 1 ; and 

b. heuristic-based routines to match newly received data records to the key records 
in the persistent table (Col. 3, lines 37-40). 

Haimowitz does not expressly disclose iteratively cleaning the newly received data 
records by modifying the newly received data records in response to no match occurring between 
the received data records and the key records in the persistent table. 

Commons discloses an iterative process for finding a matching database record 
(Commons: para. 0058, lines 1-3). Commons further discloses using a search key that is 



1 The candidate records (key record) are associated with the existing records (clean data records) in the database. 
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matched against records that are stored in the database (Commons: para. 0058, lines 4-6, 10-11). 
If a match is not found on the first try, the search is repeated (matching is repeated) with 
progressively less specific information (iteratively cleaned) (Commons: para. 0060, lines 1-3). 
This process is repeated until a match is found or it is determined that no matching records exist 
(Commons: Figs. 3A, 3B; para. 0060-63). 

Haimowitz and Commons are analogous art because they are directed to the same field of 
endeavor of data storage and retrieval. 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the tool of Haimowitz by adding the feature of iteratively cleaning the newly received 
data records by modifying the newly received data records in response to no match occurring 
between the received data records and the key records in the persistent table, as taught by 
Commons. 

The motivation for doing so would have been because iteratively cleaning the input data 
and performing a matching process to retrieve data is fast and accurate process for retrieving data 
(Commons: para. 0058, lines 1-3). Furthermore, since the process is iterative, manual 
intervention following a failed matching step is no longer required and thus provides 
convenience and speed. 

In regards to claim 4, Haimowitz discloses wherein each said clean data record is a 
completely clean data file (Haimowitz: Col 3, lines 61-67; col. 4, lines 1-61). 
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In regards to claim 5, Haimowitz discloses the tool as set forth in claim 1 further 
comprising: at least one column recording one or more of said heuristic-based routines that were 
involved in generating each of said key records (Col. 5, lines 1-4, 50-67; col. 6, lines 6-10) . 

In regards to claims 7 and 8, Haimowitz discloses special flags associated with said key 
records, said flags are a quality factor assigned to each said key record (col. 5, lines 31-34). 

In regards to claim 23, Haimowitz discloses a method of doing business comprising: 

a. storing a database of clean data files for each of a plurality of entities (Col. 2, 
lines 62-66); 

b. creating a tabulation of crude keys, each having a pointer to an associated one of 
said clean data files (Col. 3, lines 34-47; col. 4, lines 65-67; col. 5, lines 1-8) 3 ; 

c. receiving a dirty data record related to at least one entity of said plurality of 
entities (Col. 3, lines 32-33) 4 ; 

d. comparing said dirty data record to said tabulation (Col. 3, lines 37-40; col. 6, 
lines 11-18) 5 ; 

e. assigning said dirty data record to one of said clean data files if a match is found 
based on the comparing(Col. 6, lines 20-2 1) 6 ; and 

f. comparing the dirty data record to said tabulation (Col. 6, lines 1 1-22). 

2 The hash key field is interpreted as heuristic based routines because they are functions used to generate candidates 
(key records). 

3 The candidate set is interpreted as a tabulation of crude keys. Each of the candidates is related to an existing entry 
in the database. This is interpreted as having a pointer to a clean data file. 

4 A new record is received is interpreted as receiving a dirty record related to at least one entity of said plurality of 
entities. 

5 Matching (comparing) between the new record (dirty data) and each of the candidates (tabulation) is performed. 

6 If a match is found the new record (dirty data) is used to update (assigned) the existing record (clean data file) 
associated with the matched candidate. 
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Haimowitz does not expressly disclose cleaning the dirty data record by modifying the 
dirty data record in response to determining that no match is present based on the comparing. 

Commons discloses an iterative process for finding a matching database record 
(Commons: para. 0058, lines 1-3). Commons further discloses using a search key that is 
matched against records that are stored in the database (Commons: para. 0058, lines 4-6, 10-11). 
If a match is not found on the first try, the search is repeated (matching is repeated) with 
progressively less specific information (iteratively cleaned) (Commons: para. 0060, lines 1-3). 
This process is repeated until a match is found or it is determined that no matching records exist 
(Commons: Figs. 3A, 3B; para. 0060-63). 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the method of Haimowitz by adding the feature of cleaning the dirty data record by 
modifying the dirty data record in response to determining that no match is present based on the 
comparing. 

The motivation for doing so would have been because iteratively cleaning the input data 
and performing a matching process to retrieve data is fast and accurate process for retrieving data 
(Commons: para. 0058, lines 1-3). 

In regards to claim 15, Haimowitz discloses a computer memory (Col. 2, lines 61-63) 
comprising: 

a. computer code means for receiving an input data record (Haimowitz: Col. 3, lines 
32-33); 
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b. computer code means for comparing said input data record to a tabular format set 
of crude keys (Haimowitz: Col. 3, lines 37-40); 

c. computer code means for returning a clean key associated with one of said crude 
keys upon a comparing match (Haimowitz: col. 6, lines 18-20) 7 ; 

d. computer code means for creating a new crude key from said input data record 
such that said new crude key is added to the set of crude keys (Haimowitz: col. 6, lines 
19-20; col. 9, lines 58-64). 

Haimowitz does not expressly disclose computer code means for iterative cleaning of 
said input data record upon a no-match return and storing the iteratively-generated respective 
cleaned input data record therefrom, computer code means for re-comparing said iteratively- 
generated respective cleaned input data record to said set of crude keys, and computer code 
means for creating a new crude key from a last said iteratively-generated respective cleaned 
input data record. 

Commons discloses an iterative process for finding a matching database record 
(Commons: para. 0058, lines 1-3). Commons further discloses using a search key that is 
matched against records that are stored in the database (Commons: para. 0058, lines 4-6, 10-1 1). 
If a match is not found on the first try, the search is repeated (matching is repeated) with 
progressively less specific information (iteratively cleaned) (Commons: para. 0060, lines 1-3). 
This process is repeated until a match is found or it is determined that no matching records exist 
(Commons: Figs. 3A, 3B; para. 0060-63). 



7 When a match is found, the existing record (clean key) associated with the matched candidate (crude key) is 
accessed (returning). 
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Haimowitz and Commons are analogous art because they are directed to the same field of 
endeavor of data storage and retrieval. 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the computer memory of Haimowitz by adding computer code means for iterative 
cleaning of said input data record upon a no-match return and storing the iteratively-generated 
respective cleaned input data record therefrom, computer code means for re-comparing said 
iteratively-generated respective cleaned input data record to said set of crude keys, and computer 
code means for creating a new crude key from a last said iteratively-generated respective cleaned 
input data record, as taught by Commons. 

The motivation for doing so would have been because iteratively cleaning the input data 
and performing a matching process to retrieve data is fast and accurate process for retrieving data 
(Commons: para. 0058, lines 1-3). Furthermore, since the process is iterative, manual 
intervention following a failed matching step is no longer required and thus provides 
convenience and speed. 

In regards to claim 17, Haimowitz discloses the computer memory as set forth in claim 
15 wherein said computer code means for generating a new crude key has heuristic routines 
(Haimowitz: Col. 5, lines 1-4, 50-67; col. 6, lines 6-10) 8 . 

In regards to claim 18, Haimowitz discloses the computer memory as set forth in claim 
17 further comprising: computer code means for displaying in said tabular format said crude 
keys and heuristic routines (Haimowitz: Col. 10, lines 4-18). 
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In regards to claim 19, Haimowitz discloses the computer memory as set forth in claim 
15 wherein each of said crude keys has an associated pointer to obtain said associated clean key 
(Col. 4, lines 65-67; col. 5, lines 1-8) 9 , 

In regards to claim 21, Haimowitz discloses the computer memory as set forth in claim 
15 wherein said tabular format is a displayable table, further comprising: computer code means 
including heuristic routines for editing said table (Haimowitz: col. 9, lines 30-41). 

Claim 6 is rejected under 35 U.S.C. 103(a) as being unpatentable over Haimowitz et al. (US 
Patent 5,819,291) of record, hereinafter "Haimowitz", in view of Commons et al. (US 
Patent Pub 2002/0069195) of record, hereinafter "Commons", further in view of Mori et al. 
(US Patent 5,806,058) of record, hereinafter "Mori". 

In regards to claim 6, Haimowitz and Commons do not expressly disclose a time-stamp 
associated with each said key record in the table wherein said time-stamp is indicative of most 
recent use. . 

Mori discloses an index record (key record) having a time access (time-stamp) field that 
indicates the time the index record was most recently used (Mori: col. 3, lines 45-47). 

Haimowitz, Commons and Mori are analogous art because they are directed to the same 
field of endeavor of database management with indices. 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the combined tool of Haimowitz and Commons by adding a time-stamp associated 



8 The hash key field is interpreted as heuristic based routines because they are functions used to generate candidates 
(key records). 

9 Each of the candidates (crude keys) generated are associated with an existing record (clean key) in the database. 



Application/Control Number: 10/733,750 Page 10 

Art Unit: 2163 

with each said key record in the table wherein said time-stamp is indicative of most recent use, as 
taught by Mori. 

The motivation for doing so would have been because a timestamp indicating the most 
recent use of the index key would be useful in determining what indices are no longer useful and 
could potentially be deleted. An index that has not been accessed for a long time is most likely 
no longer useful and can be deleted to conserve space and increase the efficiency and speed of 
the database system (Mori: col. 1, lines 40-47, 59-62). 

Claims 9-13 are rejected under 35 U.S.C. 103(a) as being unpatentable over Haimowitz et 

al. (US Patent 5,819,291) of record, hereinafter "Haimowitz" in view of Commons et al. (US 

i 

Patent Pub 2002/0069195) of record, hereinafter "Commons", further in view of Kuga et ah 
(US Patent 5,276,616) of record, hereinafter "Kuga", 

In regards to claim 9, Haimowitz discloses a data association and cleaning method 
comprising: 

a. storing a plurality of clean data files and, associated with each of said clean data 
files, at least one indexing record, each said indexing record containing at least one field 
related to a respective associated clean data file such that said at least one indexing record 
serves as a pointer to the respective associated said clean data file (Haimowitz: Col. 2, 
lines 62-66; col. 3, lines 35-37; col. 4, lines 65-67; col. 5, lines 1-8) 10 ; 



10 A database of existing records is stored (clean data files). Associated with the existing records are candidates 
(indexing record). The candidate set is related to the associated existing record and serves as a method of accessing 
the clean data file (pointer to respective associated clean data file). 
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b. comparing an input data record to the indexing records for obtaining a match, and 
if the match occurs, assigning said input data record to the respective associated said 
clean data file (Haimbwitz: col. 3, lines 31-43; col. 6, lines 1 1-2 1) 1 1 ; and 

c. upon no match, adding said cleaned input data record as a new clean data file with 
an associated indexing record therefor (Haimowitz: col. 6, lines 18-21) 12 . 

Haimowitz does not expressly disclose if the match does not occur, iteratively cleaning 
the input data record until at least a near-match between said cleaned input data record and at 
least one of the indexing records is obtained and assigning said cleaned input data record to the 
one of said clean data files associated with the near-matched indexing record and upon a near 
match, adding said cleaned input data record as a new indexing record for the associated one of 
said clean data files. 

Commons discloses an iterative process for finding a matching database record 
(Commons: para. 0058, lines 1-3). Commons further discloses using a search key that is 
matched against records that are stored in the database (Commons: para. 0058, lines 4-6, 10-11). 
If a match is not found on the first try, the search is repeated (matching is repeated) with 
progressively less specific information (iteratively cleaned) (Commons: para. 0060, lines 1-3). 
This process is repeated until a match is found or it is determined that no matching records exist 
(Commons: Figs. 3A, 3B; para. 0060-63). 

Kuga discloses an apparatus for generating an index from input data (Kuga: col. 5, lines 
9-11). A matching module matches input data to an existing entry in a dictionary (database) to 

11 An input data record is matched with each of the candidates (indexing record) to obtain a match. If a match is 
obtained then the input data record is used to update (assigned) the associated existing record in the database (clean 
data file) associated with the matched candidate (indexing record). 

12 If no match is found the input data is inserted into the database (adding input data record as a new clean data file). 



Application/Control Number: 10/733,750 Page 12 

Art Unit: 2163 

determine a match. When there is a substantial match or an exact match, an index entry is 
generated and associated with the existing entry (Kuga: col. 13, lines 26-45). 

Haimowitz, Commons and Kuga are analogous art because they are directed to the same 
field of endeavor of data storage and retrieval. 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the method of Haimowitz by adding the steps of iteratively cleaning the input data 
record until at least a near-match between said cleaned input data record and at least one of the 
indexing records is obtained and assigning said cleaned input data record to the one of said clean 
data files associated with a near-matched indexing record upon no match, as taught by Commons 
and adding said cleaned input data record as a new indexing record for the associated one of said 
clean data files upon obtaining a match, as taught by Kuga. 

The motivation for doing so would have been because iteratively cleaning the input data 
and performing a matching process to retrieve data is fast and accurate process for retrieving data 
(Commons: para. 0058, lines 1-3). Furthermore, since the process is iterative, manual 
intervention following a failed matching step is no longer required and thus provides 
convenience and speed. The motivation for creating an indexing record upon a match would 
have been because manual index creation is burdensome and inconsistent (Kuga: col. 1, lines 47- 
68). 

In regards to claim 10, Haimowitz discloses the method as set forth in claim 9 wherein 
said storing is in a displayable format (Haimowitz: Fig. 5). 
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In regards to claim 11, Haimowitz discloses the method as set forth in claim 10 further 
comprising: at given intervals, performing a data clean-up on a stored table in said displayable 
format (Haimowitz: Fig. 5; col. 9, lines 30-32; col. 10, lines 4-6, 9-1 8) 13 . 

In regards to claim 12, Haimowitz discloses the method as set forth in claim 9 wherein 
upon said adding said cleaned input data record as a new clean data file with an associated 
indexing record therefor, flagging said new clean data file (Haimowitz: col. 9, lines 58-64) 14 . 

Claim 13 was addressed above in the rejection to claim 9 as being disclosed by 
Haimowitz and Commons. Haimowitz and Commons disclose said iteratively cleaning 
(Commons: para. 0058, lines 1-3) further comprising: 

a. cleaning said input data record and storing a first cleaned input data record 
(Commons: para. 0060, lines 1-3); 

b. comparing the first cleaned input data record to said indexing records (Commons: 
para. 0060, lines 1-3), and 

i. upon recognizing a match therebetween, stopping said comparing, and 
retrieving the associated clean data file for association with said first cleaned 
input data record (Commons: Figs. 3A, 3B; para. 0060-63), 

ii. upon not recognizing a match therebetween, re-cleaning said first cleaned 
input data record, discarding said first cleaned input data record, and storing it as 
a subsequently cleaned input data record; (Commons: Figs. 3A, 3B; para. 0060- 
63) 

13 An administrator can add additional rules and choose indices at given intervals using the graphical user interface 
shown in figure 5 (displayable format). 

14 The new customer ID generated for the new record is interpreted as flagging the new entry (new clean data file). 
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c. re-comparing the subsequently cleaned input data set to said indexing records 
(Commons: Figs. 3A, 3B; para. 0060-63); and 

d. iteratively repeating said re-cleaning and re-comparing until a predetermined 
phase of cleaning is reached and no said match therebetween is determined (Commons: 
Figs. 3A 5 3B; para. 0060-63), and storing the most recent re-cleaned and re-compared 
input data record as a new clean data file (Haimowitz: col. 6, lines 18-21). 

Claim 20 is rejected under 35 U.S.C. 103(a) as being unpatentable over Haimowitz et al. 
(US Patent 5,819,291) of record, hereinafter "Haimowitz" in view of Commons et al. (US 
Patent Pub 2002/0069195) of record, hereinafter "Commons", further in view of Vagnozzi 
(US Patent 6,070,164) of record. 

In regards to claim 20, Haimowitz, Commons and Kuga do not expressly disclose each of 
said crude keys points to a cleanest one of a plurality of crude keys associated with a clean data 
file. 

Vagnozzi discloses data values stored in a database that are associated with fine keys 
(cleanest key), which are in turn associated with one or more coarse keys (crude keys) 
(Vagnozzi: col. 3, lines 23-45). 

Haimowitz, Commons, Kuga and Vangozzi are analogous art because they are directed to 
the same field of endeavor of database systems using indices. 

At the time of the invention, it would have been obvious to one of ordinary skill in the art 
to modify the combined computer memory of Haimowitz, Commons and Kuga by making each 
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of said crude keys points to a cleanest one of a plurality of crude keys associated with a clean 
data file, as taught by Vagnozzi. 

The motivation for doing so would have been because it allows for fast query responses 
by minimizing the number of key indices required (Vagnozzi: col. 2, lines 65-67; col 3, lines 1- 
17,21-23). 

(10) Response to Argument 
A. Response to Appellants arguments in regards to the rejection of claims 1, 4, 5, 7, 8, 
15, 17-19, 21 and 23 under 35 U.S.C, 103(a) over Haimowitz in view of Commons, 

Appellant argues the claims in groups, therefore the arguments will be addressed in 
corresponding groups. Since the claims are rejected under 35 U.S.C. 103(a), the requirement is 
that a prima facie case of obviousness be established. For a prima facie case of obviousness to 
be established, three elements must be met. 

(1) All the limitations of the claims must be disclosed by the references. 

(2) There must be a reasonable expectation of success for the combination. 

(3) There must be a motivation or suggestion to combine that can be found in the 
references or in knowledge commonly available to one of ordinary skill in the art. 

In each of the subgroups below, Appellant alleges that the Examiner fails to satisfy one or more 
of the required elements of a prima facie case of obviousness. However, it is shown that all the 
elements of a prima facie case of obviousness are satisfied rendering the rejections under 35 
U.S.C. 103 proper. 
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A.l Claims 1, 4, 5, 7 and 8 are unpatentable under 35 U.S.C. 103(a) over Haimowitz in 
view of Commons because the combination of Haimowitz and Commons (1) disclose all the 
limitations of the claims and (2) there was a motivation to combine Haimowitz with 
Commons. 

In regards to argument (1), Appellant alleges that the combination of Haimowitz and 
Commons fails to disclose all the limitations of the claims. In particular, Appellant alleges that 
the combination fails to disclose "heuristic-based routines to iteratively clean the newly received 
data records by modifying the newly received data records in response to no match occurring 
between the received data records and the key records in the persistent storage" (Brief at 5-6.) 
Appellant contends that the method of matching data records disclosed in Commons is different 
from the method of matching data records of the claim (Brief at 6.) The Examiner respectfully 
disagrees. 

As summarized by Appellant, Commons discloses an iterative process for finding a 
database record by iteratively determining a match using a search key for each iteration. 
Commons at Fig. 3 A, 3B; para. 0058; para. 0060-63. Appellant contends the limitation 
distinguishes from Commons because: (a) the Examiner confused data records for key records 
and as a result, Commons does not properly map to the elements of the limitation and (b) 
"cleaning a newly received data record" by "modifying the newly received data record" is not 
the same as generating search keys based on less specific information, as disclosed by Commons 
(Brief at 7-8.) 

In regards to argument (a), the Examiner had no such confusion. As noted by Appellant, 
claim 1 recites a persistent table having clean data records and key records (Brief at 7.) This 
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limitation was disclosed by Haimowitz and not by Commons. See Haimowitz at col. 2, lines 63- 
6; col. 4, lines 65-7; col. 5, lines 1-8. In addition, Haimowitz discloses heuristic-based routines 
to match newly received data records to the key records in the persistent table. Haimowitz at col. 
3, lines 37-40. Commons was relied upon for the disclosure of an iterative matching process, 
which is not expressly disclosed by Haimowitz. As such, the Examiner maps the search keys of 
Commons to the "newly received data record" of the claim and the database records of commons 
to the "key records" of the claim. More explanation on how Commons maps to the limitation 
will be addressed below with respect to argument (b). Thus, there was no confusion in relying 
upon Commons. 

In regards to argument (b), Appellant contends the iterative generation of search keys in 
Commons is not the same as "cleaning a newly received data record by modifying the newly 
received data record" (Brief at 7.) The Examiner respectfully disagrees. The limitation defines 
"cleaning" as "modifying." Commons discloses generating a first search key to perform a search 
and upon no match being found, generating a second search key with less specific information. 
This iterative process continues until a match is found or the least specific information has 
already been used. Commons at para. 0058; para. 0060-03. Appellant argues that this iterative 
process is different from the "cleaning" of the limitation because the search keys are generated 
based on different information (Brief at 7.) On the contrary, the search keys are generated based 
on the same information, however, less specifics of the information are used for each iteration of 
the search key. The information listed in para. 0057 of Commons is used as the basis for 
generating the search keys. Each generated search key simply uses information that is less 
unique than the previous search key. In addition, each search key is a hash code generated based 
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on the information that is predetermined for each iteration. Commons at para 0058. Since all the 
keys are based on the same information, except with each generated search key, less unique 
information is used, the Examiner interprets that all the generated keys are simply modifications 
of the first generated search key. For example, if the first search key is generated based on the 
most unique information A, B, C, D and E and no match is found, the second search key would 
be generated using less unique information A, B, C and D. Essentially, the information used to 
generate the search key is modified and as a result, the generated search key is modified. Thus, 
the search key (i.e. newly received data record) is "cleaned" by "modifying" it. Since the 
combination of Haimowitz and Commons disclose all the limitations of the claims for the 
reasons above, the first element of a prima facie case of obviousness is satisfied. 

In regards to argument (2), Appellant also alleges that there is no motivation to combine 
Haimowitz with Commons (Brief at 8.) The Examiner respectfully disagrees. A suggestion or 
motivation to combine must be found in the references or in knowledge commonly available to 
one of ordinary skill in the art. In this case, the motivation to combine Haimowitz with 
Commons comes from both the reference and knowledge commonly available to one of ordinary 
skill in the art. Commons discloses using an iterative process to find matching database records 
as quickly and as accurately as possible. Commons at para. 0058, lines 1-3. In addition, iterative 
processing is commonly known to one of ordinary skill in the art because it allows for 
unsupervised processing while maintaining speed and accuracy. For example, the processing in 
Commons generates a first search key, based on the most unique information, to search for a 
matching database record. Once it is determine that there is no matching database record, a 
second search key is generated based on less unique information and the search is performed 
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again with the second search key. There is no need for user interaction once no match was found 
with the first search key. The process would continue until a match is found or the least specific 
information has been used. As a result, there is no need for supervision and accuracy is 
maintained since the most unique search key will be matched, if there is a match at all. Thus, the 
motivation to combine Haimowitz with Commons would be to increase the speed and accuracy 
of finding a match. Appellant contends that there is no motivation because Haimowitz and 
Commons are allegedly nonanalogous art (Brief at 8-9.) However, Haimowitz and Commons 
are analogous art because they are directed toward the same field of endeavor of database 
searching and retrieval. Although the specifics and purpose of their respective inventions may 
be different, the underlying basics of their inventions are the same. 

For the reasons stated above, the Examiner asserts that Haimowitz and Commons 
disclose all the limitations of the claims and that there is a motivation to combine Haimowitz 
with Commons found in the reference and in knowledge available to one of ordinary skill in the 
art. As a result, a prima facie case of obviousness is established rendering the rejection under 35 
U.S.C. 103 proper. It is respectfully requested that the Board sustain the rejection of claims 1, 4, 
5, 7 and 8 under 35 U.S.C. 103(a) over Haimowitz in view of Commons. 

A.2 Claim 23 is unpatentable under 35 U.S.C. 103(a) over Haimowitz in view of 
Commons because the combination of Haimowitz and Commons discloses all the 
limitations of claim 23. 

Appellant alleges that the combination of Haimowitz and Commons fails to disclose all 
the limitations of claim 23 (Brief at 9-10.) Claim 23 recites similar subject matter as claim 1, 
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which has been addressed above in section A.l. Appellant notes that claim 23 recites "clean data 
files," "crude keys" and "dirty data record" indicating that these items are different items (Brief 
at 10) as reasons for distinguishing from Commons. In regards to the "clean data files," 
Haimowitz discloses a database of files, which are interpreted as "clean data files". Haimowitz 
at col. 2, lines 62-66. In regards to the "crude keys," Haimowitz discloses a candidate set of 
records (i.e., crude keys). Haimowitz at col. 3, lines 34-47. In regards to a "dirty data record," 
Haimowitz discloses a new record, which is interpreted as a "dirty data record." Haimowitz at 
col. 3, lines 32-3. With respect to Commons, the first search key generated is interpreted as a 
"dirty data record," which is "cleaned" when the second search key is generated from less unique 
information. As a result, Haimowitz combined with Commons results in the comparison of a 
"cleaned dirty data record to the tabulation" as recited in claim 23. Thus, the combination of 
Haimowitz and Commons disclose all the limitations of claim 23 as discussed above in section 
A.l and as explained in this section. 

For these reasons, a prima facie case of obviousness is established rendering the rejection 
of claim 23 under 35 U.S.C. 103 proper. It is respectfully requested that the Board sustain the 
rejection of claim 23 under 35 U.S.C. 103(a) over Haimowitz in view of Commons. 

A.3 Claims 15, 17-19 and 21 are unpatentable under 35 U.S.C. 103(a) over Haimowitz in 
view of Commons because the combination of Haimowitz and Commons (1) disclose all the 
limitations of the claims and (2) there was a motivation to combine Haimowitz with 
Commons. 
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Appellant mainly argues with respect to the limitations of claim 15. Claim 15 recites 
subject matter similar to claim 1 in the form of a computer memory comprising computer code. 
Therefore, the arguments in regards to subject matter similar to claim 1 are addressed with the 
same rationale as discussed in section A.l. In addition, arguments in regards to the motivation to 
combine Haimowitz and Commons have also been addressed above in section A.L 

In addition, Appellant raises an issue regarding the limitation of "a last said iteratively- 
generated respective cleaned input data record such that said new crude key is added to the set of 
crude keys," recited in claim 15 and not in claim 1. Appellant alleges that combination of 
Haimowitz and Commons fails to disclose the limitation because there is no suggestion in 
Commons (Brief at 1 1 .) The Examiner respectfully disagrees. The limitation is disclosed by the 
combination of Haimowitz and Commons. Haimowitz discloses creating a new crude key from 
the input data record such that said new crude key is added to the set of crude keys. Haimowitz 
at col. 6, lines 19-20; col. 9, lines 58-64. Therefore, what requires modification is changing the 
input data record of Haimowitz to the iteratively cleaned input data record, disclosed by 
Commons. As discussed previously, Commons discloses generating a first search key to 
perform a search with and upon no match being found, generating a second search key with less 
specific information. This iterative process continues until a match is found or the least specific 
information has already been used. Commons at para. 0058; para. 0060-03. Also as discussed 
previously, the iterative process using less specific information in each iteration is interpreted as 
"cleaning." Therefore, the "cleaning" of Commons can be used to modify the input data record 
of Haimowitz to create an iteratively cleaned input data record since only the steps of iteratively 
cleaning the input data record are missing from Haimowitz. As a result, the combination of 
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Haimowitz and Commons discloses "a last said iteratively generated respective cleaned input 
data record such that said new crude key is added to the set of crude keys. 

For the reasons stated above, the Examiner asserts that Haimowitz and Commons 
disclose all the limitations of the claims and that there is a motivation to combine Haimowitz 
with Commons found in the reference and in knowledge available to one of ordinary skill in the 
art. As a result, a prima facie case of obviousness is established rendering the rejection under 35 
U.S.C. 103 proper. It is respectfully requested that the Board sustain the rejection of claims 15, 
17-19 and 21 under 35 U.S.C. 103(a) over Haimowitz in view of Commons. 

B. Response to Appellant's arguments in regards to the rejection of claim 6 under 35 
U.S.C. 103(a) over Haimowitz in view of Commons and Mori. 

Appellant's arguments reference the arguments presented with respect to claim 1, which 
have been addressed above in Section A.l . Appellant presents no further arguments with respect 
to claim 6. Therefore, it is respectfully requested that the Board affirm the final rejection of 
claim 6. 

C. Response to Appellant's arguments in regards to the rejection of claims 9-13 under 
35 U.S.C. 103(a) over Haimowitz in view of Commons and Kuga. 

Claims 9-13 are rejected under 35 U.S.C. 103(a), the requirement is that a prima facie 
case of obviousness be established. As discussed in section A above, for a prima facie case of 
obviousness to be established, three elements must be met. 
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C.l Claims 9-13 are unpatentable under 35 U.S.C. 103(a) over Haimowitz in view of 
Commons and Kuga because the combination of Haimowitz, Commons and Kuga (1) 
disclose all the limitations of the claims and (2) there was a motivation to combine 
Haimowitz with Commons and Kuga. 

In regards to argument (1), Appellant alleges that the combination of Haimowitz, 
Commons and Kuga fail to disclose (a) "if the match does not occur, iteratively cleaning the 
input data record until at least a near-match between the cleaned input data record and at least 
one of the indexing records is obtained, and assigning the cleaned input data record to the one of 
the cleaned data files associated with the near-matched indexing record" and (b) "upon a near 
match, adding the cleaned input data record as a new indexing record for the associated one of 
the clean data files, and upon no match, adding the cleaned data record as a new clean data file 
with an associated indexing record therefor" recited in claim 9 (Brief at 12.) The Examiner 
respectfully disagrees. 

In regards to limitation (a), as discussed above in relation to claims 1 and 15, Commons 
discloses generating a first search key to perform a search with and upon no match being found, 
generating a second search key with less specific information. This iterative process continues 
until a match is found or the least specific information has already been used. Commons at para. 
0058; para. 0060-03. The Examiner asserts this feature of Commons, used to modify 
Haimowitz, discloses limitation (a) of claim 9 for the reasons discussed above in section A in 
regards to the interpretation of "cleaning." Thus, Haimowitz in combination with Commons 
discloses limitation (a). 
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In regards to limitation (b) 5 Kuga discloses an apparatus for generating an index from 
input data (Kuga at col. 5, lines 9-1 1), a matching module that matches input data to an existing 
entry in a dictionary (i.e., database) to determine a match and when there is a substantial match 
(i.e., near match) or an exact match, an index entry is generated and associated with the existing 
entry. Kuga at col. 13, lines 26-45. As stated in the rejection, Haimowitz discloses the second 
part of limitation (b). Haimowitz discloses upon no match, adding said cleaned data record as a 
new clean data file with an associated indexing record therefor. Haimowitz at col. 6, lines 18-21 . 
Essentially, Haimowitz discloses that if no match is found, the input data is inserted into the 
database (i.e., adding input data record as a new clean data file). Thus, Kuga was only relied 
upon for the first part of limitation (b). In this regard, mapping the first part of limitation (b), 
Kuga discloses upon a substantial match (i.e, near match), generating an index entry (i.e., adding 
the cleaned input data record as a new indexing record) and associating it with the existing entry 
(i.e., for the associated one of the clean data files). Appellant argues that Kuga "fails to teach or 
hit at adding a cleaned input data record as a new indexing record for an associated one of the 
clean data files upon occurrence of a near match" (Brief at 13.) In support of this allegation, 
Appellant analyzes the cited portion of Kuga in column 13 and erroneously concludes that "the 
original text ■. '. . has not been cleaned; rather, it is the original text portion . . . that is stored" (Brief 
at 14.) Contrary to Appellant's allegation and premature conclusion, Kuga explicitly states 
"[t]he information outputted to index entry storage may not be a morpheme itself but may be an 
inflexion or a variant thereof." Kuga at col. 13, lines 51-3. Therefore, as asserted by the 
Examiner, Kuga does disclose adding a cleaned input data record. Thus, Haimowitz, in 
combination with Commons and Kuga, disclose all of limitation (b). 
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As a result, the combination of Haimowitz, Commons and Kuga disclose all of limitation 
(a) and (b) and accordingly, all of claim 9. Consequently, the first element of a prima facie case 
of obviousness is satisfied. 

In regards to argument (2), Appellant alleges that there is no motivation to combine 
Haimowitz with Commons and Kuga. As explained in the Final Office Action at paragraph 78, 
all the references disclose methods of searching a database with a given entry. Commons and 
Kuga disclose additional features and modifications to the method that increase speed and 
efficiency. As required to establish a prima facie case of obviousness, the motivation or 
suggestion must be found in the references or in knowledge commonly available to one of 
ordinary skill in the art. In this case, the motivation can be found in both the references and in 
knowledge commonly available to one of ordinary skill in the art. Accordingly, the third 
element of a prima facie case of obviousness is satisfied. 

For the reasons stated above, the Examiner asserts that Haimowitz, Commons and Kuga 
disclose all the limitations of the claims and that there is a motivation to combine Haimowitz 
with Commons and Kuga found in the references and in knowledge available to one of ordinary 
skill in the art. As a result, a prima facie case of obviousness is established rendering the 
rejection under 35 U.S.C. 103 proper. It is respectfully requested that the Board sustain the 
rejection of claims 9-13 under 35 U.S.C. 103(a) over Haimowitz in view of Commons and Kuga. 

D. Response to Appellant's arguments in regards to the rejection of claim 20 under 35 
U.S.C, 103(a) over Haimowitz in view of Commons and Vagnozzi. 
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Appellant's arguments reference the arguments presented with respect to claim 15, which 
have been addressed above in section A.3. Appellant presents no further arguments with respect 
to claim 20. Therefore, it is respectfully requested that the Board affirm the final rejection of 
claim 20. 

(11) Related Proceeding(s) Appendix 

No decision rendered by a court or the Board is identified by the examiner in the Related 
Appeals and Interferences section of this examiner's answer. 
Conclusion 

For the above reasons, it is respectfully requested that the Board sustain the rejections. 
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